ShimYuseob
  • 인프콘
  • 후기

2024 인프콘 정리 [지속 성장 가능한 설계를 만들어 가는 방법]

인프런에서 주최한 2024 컨퍼런스에서 배우고 알게된 경험을 잊지않기 위한 기록
2024.08.080 views

인프런에서 주최한 컨퍼런스를 신청했는데, 운좋게 당첨이 되어 참여할 수 있는 기회가 되었다.

컨퍼런스에서 알게된 경험을 잊지않기 위해, 개발팀 동료들에게 정확하게 전달할 수 있도록 정리하려 한다.

내가 참여한 세션의 시간표는 이렇다. 오프닝과 클로징은 참여하지 않았고, 코엑스에서 진행해서 그런지 인프콘 참가자를 포함해 많은 인파에 밀려 점심식사가 늦어졌고 본의아니게 휴게시간을 갖게 되었다.

첫 번째 세션 시간표


첫 번째 세션부터 정리한 내용을 다시한번 복습하며 정리하려 한다.

1. 지속 성장 가능한 설계를 만들어가는 방법#

첫 번째 지속 성장 가능한 설계를 만들어가는 방법 세션은 토스페이먼츠 개발자의 세션이였는데, "설계를 잘 하는 방법" 이라는 타이틀에 끌려 듣게되었다.

일반적인 개발 과정은 계획 > 요구사항 > 분석 > 설계 > 구현 > 테스트 > 운영 이런 과정으로 진행되는데, 설계를 잘 하는 방법이 설계를 하지 않는 것 이라고 한다.

처음에는 이해가 되지 않았는데, 본인의 설계 방식을 설명해주며 설득해가는 과정을 지나고나니 어느정도 이해가 됐다.

세션 발표자가 가져온 예시와 함께 순서대로 정리해보면, 다음과 같다.

첫 번째 예시는 웹툰서비스였다. 세션 발표자는 웹툰 서비스를 개발한다면 연재, 추천, 리뷰, 찜, 소장, 포인트.. 등등 관련 기능이 많을텐데 이러한 비즈니스 로직을 개념이라고 정의했다.

그리고 개발과정에서 이러한 로직들은 서로 연관이 생기기 마련이고 자연스럽게 그룹화를 하게 된다고 했다. 이때, 중요한 점은 그룹화를 통해 각 로직을 순회할 때 강력한 규칙이 있어야 한다고 말했다.

강력한 규칙이란 각 비즈니스 로직이 서로의 영역을 쉽게 침범하지 않도록 가상의 벽을 세워 경계화 하는 것인데 이를 격벽 으로 정의했다.

예를들어 웹툰 서비스에서 포인트, 페이먼트 가 하나의 그룹이고 에피소드가 다른 그룹이라고 하면 포인트를 수정했는데, 에피소드가 변경되거나, 페이먼트가 변경되지 않는다면 잘못 설계한 것이라 말했다.


두 번째 예시는 세션 발표자의 기업 토스의 대출 서비스를 예시로 가져왔다.

대출이라는 비즈니스 로직의 그룹 하위로 대출실행, 대출상환, 대출 상품가입 등등 개념이 있다고 하면 대출 상환의 경우 상환요청시 성공실패의 상황이 있다.

여기서 상환 실패의 경우 => 상환 재시도를 할 수 있고, 기간내 상환을 하지 못해 추가이자가 발생할 수 있다.

중요한 포인트는 서비스를 고도화하면서 대출 > 상환 > 실패 > 재시도,추가이자 와 같은 개념이 발생할 수 있다는 점이다.

이때는 재시도, 추가이자연체라는 개념으로 분리해 연체연체이자로 구분해야 한다고 말했다.

중간 정리를 하자면 다음과 같다.

  1. 개념안에는 상태(성공, 실패)가 존재할 수 있고 계속해서 상태를 확장하기 보단 격벽을 세워 분리를 검토하자.
  2. 하나의 개념이 많이 사용되면 분리를 검토하자.
  3. 상태에 의해 개념이 생기면 격벽을 세워보자.
  4. 상태나 행위를 개념으로 착각하지 않도록 주의하자.

마지막 세번째 예시는 커머스를 가져왔다.

고객/전시/상품... 등의 개념과 외부 연동사가 존재한다고 가정한다.

외부 연동사는 개념으로 구분하면 안된다고 한다. 예를 들어 모니터링, 테스팅, 외부연동사 등은 개념에 속하지 않는다.

개념도 계층(1급, 2급, 3급 ...)이 있고 격벽도 세기(강, 중, 약 ...)가 있다.

외부연동사는 개념이 없기 때문에 DB에서만 관리되어야 하고, 강력한 격벽인 참조 불가의 벽 이 있다고 했다.

정리하면

  1. 개념에도 계층이 있다.
  2. 모든것이 개념이 되지는 않는다. (구별하는 통찰력을 기르자)
  3. 개념 영역을 분리할 수 있다.

마무리로 소프트웨어를 만들면서 지켜야 할 내용들에 대해 언급했다.

소프트웨어를 만들면서

  • 인정해야한다
    • 요구사항은 항상 변한다
    • 완벽한 설계란 없다
    • software는 soft 해야한다.
  • 하지 말아야한다.
    • 요구사항이 완벽해야 설계 가능하다
    • 우리 설계에서 그건 개발 못한다.
    • 설계해봐야 개발 일정이 나온다.
  • 상기해야한다.
    • 성급한 설계는 모든 것을 망가트린다
    • 과도한 설계는 모든 것을 망가트린다
    • 설계는 필요한 만큼만 하자

기존 설계 방식에서 위와같은 방식을 연습하다 보면 설계를 하지 않게된다고 말했다.

개발 결과물에 대해 증명 + 피드백을 받으면서 개념과 격벽을 활용하며 설계를 한다. 단, 이러한 방식을 가능하게 뒷받침해주는 요소들이 있었는데 테스트 코드를 적용할 수 있는 환경이 중요하다고 말했다.

후기#

현재 재직중인 직장에선 테스트코드를 사용하지 않고있지만, 언젠가는 경험해야 할 영역이고 관심있는 분야라 천천히 테스트코드를 학습해보려한다.

유익하다고 생각되는 세션이였고, 설계하면서 해당 내용들을 숙지하며 설계해보는 습관을 들여봐야겠다.